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Abstract 

Some  aspects  of  the  operation  of  a monitoring  system  over  a time  of  several  decades  are 
discussed.  It  is  shown,  that  the  classical  system  design  approach  with  well-defined  definition, 
development,  introduction  and  operation  phases  has  to  be  replaced  by  a network  of  parallel 
activities.  These  activities  are  driven  by  the  requirements  to  maintain  fleet  readiness  and  safe 
operation  under  the  constraints  of  shrinking  budgets  and  personnel  reduction.  Other  factors 
driving  the  need  for  adaptations  and  enhancements  are  the  obsolescence  problems  caused  by  the 
significantly  different  time  scales  for  IT  system  components  used  in  commercial  or  consumer 
oriented  applications  and  for  military  applications. 

The  most  important  source  for  modifications  in  an  engine  monitoring  system  is  the  engine  itself. 
A well-coordinated  approach  is  necessary  to  match  the  introduction  of  new  engine  hardware  with 
the  required  consequential  changes  in  all  components  of  the  monitoring  system.  High  quality  of 
the  monitoring  results  produced  during  operation  can  only  be  maintained  by  well-designed  data 
handling  procedures,  user  interfaces  and  appropriate  documentation  and  training.  There  remains  a 
practically  unavoidable  small  percentage  of  data  errors  introduced  by  human  data  handling.  Due 
to  the  potentially  severe  consequences  of  undetected  errors  in  the  life  usage  data  of  fracture 
critical  engine  components,  it  is  necessary  to  apply  suitable  plausibility  checks  that  are  derived 
from  statistical  models  of  the  life  usage  process  in  a fleet  of  engines. 

Overview 

It  is  very  likely,  that  in-service  times  will  exceed  40  years  for  existing  and  newly  designed 
-military  jet  or  helicopter  engines.  One  prerequisite  for  an  achievable  and  safe  extension  of  engine 
usage  times  is  the  application  of  engine  fatigue  life  usage  monitoring.  The  German  Air  Force 
decided  to  introduce  fleet-wide  on-board  engine  monitoring  for  the  RBI 99  engines  15  years  ago 
[BP97].  The  application  of  the  OLMOS  system  has  made  available  comprehensive  life  usage  data 
for  all  fracture  critical  parts  to  the  fleet  managers  of  the  Tornado  aircraft. 

The  operation  of  the  OLMOS  system  has  revealed  that  monitoring  systems  themselves  need  a 
considerable  amount  of  maintenance  and  adjustment.  Monitoring  systems  have  a lot  of  internal 
and  external  interfaces,  as  shown  in  Figure  1 [BPR98].  Both  hardware  and  software  cannot  be 
kept  unaltered  over  decades.  The  supposedly  cost-saving  use  of  COTS  components  causes  a 
continuous  need  for  adaptation  with  a frequency  given  by  typical  life  times  of  operating  systems, 
software  development  tools,  database  systems  and  of  course  also  of  computer  hardware.  The 
typical  mismatch  in  time  scales  between  commercial  IT  systems  and  their  military  derivatives  is 
illustrated  in  Figure  2 (Source:  [A100]).  Strategies  are  known  how  to  mitigate  both  hardware  and 
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Figure  1:  Interfaces  of  a Life  Usage  Monitoring  System  (from  [BPR98]) 
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Figure  2:  Commercial  and  Military!  Time  Scales  for  IT  Equipment  (from  [A100]) 
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Figure  3 shows  the  hardware  components  and  interfaces  of  OLMOS.  Together  with  the  high 
complexity  of  data  handling  in  the  connected  logistic  systems  of  the  air  force  and  of  industry  the 
need  for  well-organized  and  coordinated  procedures  in  the  maintenance  of  this  system  is  self- 
evident.  A failure  to  address  data  management  challenges  properly  would  waist  many  of  the 
system’s  potential  benefits  [HM98], 


Figure  3:  OLMOS  System  Overview  (Source  EADS  Dornier) 

The  main  source  of  change  requirements  is  the  engine  itself.  Even  after  20  years  of  operation,  the 
frequency  of  changes  influencing  the  monitoring  algorithms  does  not  approach  zero.  Typical  mid- 
life upgrades  (e.g.  improved  air  seals,  new  materials  for  disks  or  blades,  optimised  blade  profiles) 
may  require  substantial  modifications  or  even  complete  re-programming  of  parts  of  the  life  usage 
algorithms.  There  have  been  various  partially  still  ongoing  modifications  of  the  RBI 99  engine, 
where  the  influence  on  the  life  usage  had  to  be  checked.  Not  all  of  them  required  changes  of  the 
previously  used  algorithms,  and  sometimes  minor  changes  of  some  constants  may  "be  sufficient  to 
take  into  account  the  changes  in  engine  or  component  behaviour. 

Relation  between  Engine  Modifications  and  Monitoring  Algorithms 

Whenever  a modification  of  an  engine  component  is  planned,  developed  and  introduced,  the 
consequences  of  this  modification  on  engine  life  have  to  be  assessed.  Quite  often,  it  is  not 
sufficient  to  check  those  consequences  for  the  changed  component  itself.  As  shown  in  the 
following  examples,  seemingly  small  modifications  may  influence  adjacent  components  or  even 
the  behavior  of  the  whole  engine,  thus  requiring  an  adaptation  of  life  usage  algorithms. 

•After  some  years  of  operation  it  turned  out,  that  a certain  vibration  mode  could  occur  in  one  of 
the  compressor  blade  rows  within  a narrow  speed  band.  To  avoid  a limitation  of  the  operating 
envelope  a redesign  of  the  blade  was  performed.  The  redesigned  blade  was  heavier  than  the 
previous  one.  This  leads  to  higher  centrifugal  loads  on  the  disk,  which  have  to  be  considered  in 
the  stress  model  of  the  monitoring  algorithm.  Although  the  required  modification  would  have 
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been  rather  simple,  there  was  no  means  to  transfer  the  blade  type  information  to  the  onboard 
system  without  expensive  modifications  of  the  configuration  data  sets.  Fortunately  it  was  found, 
that  the  critical  areas  influenced  by  the  centrifugal  loads  of  the  blades  would  normally  not 
become  life  limiting,  even  when  the  heavier  blade  type  was  used.  The  final  decision  was  to 
assume  the  presence  of  the  heavier  redesigned  blade  even  in  those  cases,  when  the  old  blade  type 
was  retained. 

•As  a major  part  of  the  engine  modification  for  life  cycle  cost  optimization  a redesign  of  the  high 
pressure  compressor  blades  was  performed  to  achieve  an  increased  mass  flow  and  an  improved 
surge  margin.  The  design  constraint  was  that  no  modifications  of  the  rotor  disks  were  allowed. 
Besides  from  minor  changes  in  blade  weights,  the  most  important  consequence  was  a shift  of  the 
thermodynamic  cycle  leading  to  changed  boundary  conditions  for  heat  transfer  to  disks.  A switch 
in  the  gas  temperature  calculation  model  that  is  dependent  on  the  configuration  data  set  treats  this. 
The  model  for  the  heat  transfer  and  heat  conduction  within  the  rotor  itself  remains  unchanged. 
Nevertheless,  a considerable  software  adaptation  is  required  to  insert  the  necessary  control  flow 
into  the  monitoring  algorithms  and  to  extract  the  compressor  type  information  from  the 
configuration  data. 

•A  change  in  the  manufacturing  method  of  a disk  can  lead  to  a modification  of  residual  stresses 
with  consequences  on  the  stress  level  and  damage  calculation.  Therefore  it  is  sometimes 
necessary  to  introduce  different  configuration  codes  dependent  on  the  applied  manufacturing 
methods,  even  if  the  geometry  of  the  parts  remains  identical. 

•Modified  seal  clearances  that  are  introduced  together  with  wear  resistant  coatings  will  have  an 
influence  on  secondary  air  mass  flows.  It  has  to  be  checked  if  boundary  conditions  for  the 
temperature  calculation  of  disks  are  affected. 

•A  redesign  of  HP  turbine  nozzle  guide  vanes  was  performed  to  improve  their  cooling  and 
durability.  As  a consequence  of  the  redistribution  of  the  airflows  a shift  of  work  distribution 
between  turbine  stages  occurs.  This  in  turn  affects  the  spool  speed  ratios  between  HP,  IP,  and  LP 
spools.  Whereas  the  LP  and  HP  spool  speed  are  measured  parameters,  the  IP  spool  speed  is 
calculated  from  a mathematical  model.  This  model  has  now  to  be  adapted  to  include  the  influence 
of  the  new  guide  vane  standard. 

•The  introduction  of  single  crystal  turbine  blades  is  considered  to  be  a major  cost  saving  factor 
due  to  their  superior  material  properties  (e.g.  creep  life)  at  high  temperatures.  Unfortunately  those 
blades  tend  to  have  higher  weight  than  their  conventional  predecessors.  As  long  as  both  blade 
types  are  used  in  parallel,  the  blade  type  has  to  be  transferred  to  the  disk  stress  computation  via  a 
blade  type  code  to  take  into  account  the  change  in  centrifugal  loads.  It  even  turned  out,  that 
blades  from  different  manufacturers  systematically  used  the  limits  of  admissible  weight  tolerance 
bands,  thus  requiring  another  distinction  within  the  stress  computation. 

•A  change  in  control  system  schedules,  e.g.  a modification  of  the  idle  schedule  will  require  an 
adaptation  of  criteria  for  execution  flow  of  monitoring  algorithms.  To  avoid  the  necessity  for  a 
software  update,  a so-called  monitoring  control  parameter  set  is  used,  that  contains  constants  of 
the  algorithms,  for  which  a dependency  on  external  influences  is  known  or  suspected.  It  is  then 
sufficient  to  introduce  an  update  of  the  monitoring  control  parameters  that  has  of  course  to  be 
synchronized  with  the  introduction  of  the  related  changes  of  other  hardware  or  with  changes  of 
handling  procedures. 

Changes  of  the  monitoring  algorithms  become  also  inevitable,  if  damage  mechanisms  or  critical 
areas  not  considered  so  far  turn  out  to  be  life  limiting.  This  topic  is  discussed  in  [PB01]. 

Retrofits  of  improved  engine  components  are  nearly  never  performed  in  one  “big  bang”  action, 
maybe  excluding  emergency  fixes  caused  by  flight  safety  concerns.  A more  realistic  scenario  is 
described  in  [HC99]  with  long  times  of  overlapping  mixed  use  of  old  and  new  configurations, 
including  both  engine  hardware  and  different  versions  of  the  monitoring  algorithms. 
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Development  History 

OLMOS  has  its  roots  in  the  early  1980’s,  starting  from  the  idea,  that  most  of  the  data  required  for 
monitoring  the  engines  and  the  aircraft  structure  were  already  available  in  the  existing  data 
acquisition  box  DAU-1B  for  the  tape  based  crash  recorder,  that  is  located  in  a deployable  airfoil 
(RBA,  see  Figure  3)  on  top  of  the  rear  fuselage. 


Existing  DAU-i  B for  Tape  Crash  Recorder 
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r—rT~ T1  Retrofit  of  DAU-1C 
| '[  Installation  of  OLMOS  Ground  Stations 


Minor  Hardware  Modifications  Q (e.g.  Bleed  Signal  Fed  Into  DAU) 


Memory  Upgrade  of  Engine  Monitoring  Processor  Boards  Q 

Flight  TriBls  for  DAU-1D  [] 
Retrofit  of  DAU-1 D + Solid  State  Flight  Data  Recorder  F 


Introduction  of  New  Processor,  Flight  Trials 


for  DAU-1  E w.  DWS 


1881  82  83  84  85  86  87  88  89  90  91  92  93  94  95  96  97  98  992000 01 

Figure  4:  Time  Scales  of  OLMOS  Hardware  Development 


Figure  4 shows  the  development  steps  of  the  hardware  configuration  starting  with  the 
introduction  of  3 new  processor  boards,  two  of  which  were  dedicated  to  the  engine  monitoring 
functions.  There  was  an  incremental  approach  in  both  hardware  and  software  development.  Major 
development  steps  occurred  with  the  introduction  of  the  new  engine  standard  Mkl05,  that  is  used 
to  power  the  ECR  Tornado  and  with  the  replacement  of  the  obsolete  tape  based  crash  recorder  by 
a solid  state  flight  data  recorder.  The  FDR  replacement  is  now  in  its  final  phase.  On  the  engine 
monitoring  side,  the  FDR  introduction  was  used  to  implement  a memory  upgrade  and  a software 
loading  function  that  will  simplify  the  process  of  software  changes  for  the  engine  monitoring 
algorithms.  Currently  another  upgrade  of  OLMOS  is  in  its  final  phase  of  qualification.  By 
replacing  an  obsolete  data  acquisition  board  by  a state  of  the  art  microprocessor  board  it  was 
possible  to  implement  a warning  function  for  aircraft  instability  (departure  warning  system).  The 
next  upgrade  step  in  the  engine  monitoring  functions  will  be  the  inclusion  of  the  life  usage 
algorithms  for  the  so-called  life  cycle  cost  optimized  engine  that  includes  several  improvements, 
e.g.  an  HP  compressor  with  increased  mass  flow. 

Figure  5 shows  an  overview  of  the  development  history  of  the  engine  life  consumption- 
monitoring program  ELCMP.  Each  change  at  this  complex  system  requires  an  inspection  and  a 
consideration  of  numerous  existing  mutual  dependencies,  which  are  partly  so  serious  that  actually 
meaningful  extensions  or  adjustments  can  either  not  be  introduced  at  all  or  only  with  very  long 
temporal  delay.  The  continued  use  of  LUM  algorithms  known  to  be  outdated  indicated  at  the  end 
of  the  time  scale  in  Figure  5 is  caused  by  the  mutual  dependence  between  availability  of  the 
software  loading  function  for  ELCMP  into  the  onboard  DAU  and  the  necessity  to  have  only  one 
version  of  life  consumption  data  in  the  data  base  of  the  logistic  system  BMS. 
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Figure  5:  Time  Scales  of  Algorithm  Development  for  Life  Usage  Monitoring 

Problem  Tracking 

A very  important  tool  to  maintain  a high  quality  of  a monitoring  system  is  a reasonable  procedure 
for  problem  data  gathering  and  tracking.  In  the  OLMOS  system  there  exists  one  central  query  list, 
where  all  known  problems  are  collected.  Entries  come  from  all  parties  in  the  development, 
management  and  planning,  but  the  focus  is  on  reports  from  the  end  users.  This  list  is  the  basis  for 
regular  system  reviews  and  for  the  planning  of  correction  and  update  packages.  Currently  there 
are  some  150  entries  in  the  list.  70  of  these  queries  have  their  origin  in  the  introduction  phase  of 
major  system  changes,  dealing  mainly  with  requirements  that  were  set  aside  during  the 
specification  phase  (low  priority,  financial  constraints),  whereas  the  remaining  larger  part  deals 
with  problems  detected  during  system  operation. 

The  list  is  maintained  at  the  technical  training  center  of  the  GAF,  which  acts  as  an  advisor  to  the 
GAF  material  command.  This  choice  has  proven  to  be  rather  beneficial,  because  the  air  force 
personnel  assigned  to  the  OLMOS  system  visits  training  courses  before  they  start  to  work  with 
the  system.  When  problems  show  up,  that  can’t  be  solved  by  using  the  documentation  or  the 
system’s  help  functions,  in  many  cases  the  first  address  to  consult  is  the  training  center.  As  the 
query  list  contains  also  recommendations  for  a solution  of  known  problems,  it  is  sometimes 
possible  to  give  hints  how  a problem  may  be  solved  manually  or  be  circumvented  until  it  is 
solved  by- a system  patch  or  update. 

User  Training  Environment 

The  environment  of  the  training  center  is  also  used  during  tests  of  new  features  to  be  incorporated 
into  the  monitoring  system.  A very  useful  feature  is  the  presence  of  virtual  aircraft  and  engine 
data  in  the  productive  database  of  the  BMS  system  operated  by  the  material  support  command. 
All  data  records  used  for  training  purposes  have  unique,  easily  recognizable  serial  numbers  that 
have  no  correspondence  in  the  form  of  existing  engine  hardware.  It  is  of  course  necessary  to 
exclude  those  parts  during  statistical  analyses  or  during  productive  database  queries  by  means  of 
suitably  defined  import  filters.  By  means  of  this  construction  it  is  possible  for  the  OLMOS 
personnel  to  practice  all  occurring  handling  procedures,  including  also  the  data  transfers  to  and 
from  the  central  logistic  system. 

To  simulate  the  consequences  of  flight  operations  on  the  onboard  data  acquisition  unit,  the  DAU 
can  be  fed  with  aircraft  and  engine  data  via  two  different  interfaces.  It  is  either  possible  to  use  the 
serial  link  for  the  HHT  in  a special  transfer  mode  to  send  digital  engine  data  or  to  stimulate  the 
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analog  and  digital  interfaces  using  a dedicated  test  rig  (SSTU)  with  the  same  data  the  DAU  would 
see  in  the  aircraft.  In  both  cases  synthetic  or  real  recorded  engine  runs  can  be  used  as  input.  This 
function  has  proved  to  be  extremely  valuable  to  verify  the  correct  operation  of  the  onboard 
components  of  OLMOS. 

Plausibility  Checks  for  Life  Usage  Data 

Another  area  of  improvement  is  the  elimination  of  manual  handling  of  life  usage  data.  Human 
interaction  always  produces  some  low,  but  nearly  unavoidable  percentage  of  errors  in  the  data. 
Besides  from  trying  to  eliminate  the  need  for  non-automatic  processing  steps  (e.g.  by  a better 
integration  of  the  data  processing  systems  of  the  air  force  and  of  industry),  methods  have  been 
developed  to  detect  and  correct  inconsistencies  in  the  logistic  data  by  using  suitable  checks. 

The  life  consumption  data  accumulated  in  the  onboard  systems  are  transferred  via  the  processing 
chain  indicated  in  Figure  1 and  finally  collected  in  the  BMS  database  at  the  GAF  central 
computer  facilities.  Every  month  the  life  usage  data  of  all  monitored  parts  are  extracted  from  this 
database  and  are  sent  to  industry  for  statistical  analysis.  The  results  of  the  statistical  assessment 
are  summarized  in  a monthly  status  report.  Currently  a system  for  plausibility  checks  of  those 
data  is  being  introduced.  The  basis  for  the  plausibility  checks  is  a statistical  analysis  [PB01], 
which  is  based  on  simulation  runs  using  recorded  engine  data  together  with  the  accumulated  life 
usage  data  available  in  the  logistic  system  BMS  of  the  German  air  force.  The  planned  application 
of  those  checks  will  allow  an  early  detection  of  errors  and  thus  avoid  potential  risks  of  hidden 
data  errors  on  flight  safety. 
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Figure  6:  Scatter  in  accumulated  life  usage 

Figure  6 illustrates  the  basic  idea  of  the  plausibility  check.  The  relation  between  numbers  of 
flights  and  accumulated  life  usage  is  acceptable,  when  the  relation  falls  into  the  envelope  of  the 
simulation  results.  The  results  of  the  simulation  are  tables  of  upper  and  lower  limit  values  as  a 
function  of  the  number  of  engine  runs.  There  is  one  table  per  critical  area,  thus  leading  to  more 
than  40  such  tables  for  the  whole  engine.  To  convert  those  tables  into  the  more  usual  dependence 
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on  accumulated  flight  time,  an  average  flight  time  per  flight  is  used,  that  is  either  a value  for  the 
whole  fleet  or  a specific  value  determined  for  a certain  aircraft  variant  or  for  an  air  base  with 
known  mission  types  significantly  different  from  the  fleet  average. 

The  data  handling  of  many  tables  with  several  thousands  of  entries  has  been  considered  as 
impractical  and  therefore  an  alternative  representation  of  the  limit  curves  was  required.  By 
analysis  and  numerical  experimentation  a set  of  formulas  was  found,  by  which  all  occurring  limit 
curves  could  be  represented  with  very  good  accuracy.  The  idea  is  to  use  a weighted  mean  of  two 
straight  lines  together  with  an  expansion  function  that  is  used  to  widen  the  curve  for  lower  times. 
The  following  formulas  are  used: 

• 2 straight  lines: 

gi(t)  = srt  + dl 
g2{t)  = s2-t  + d2 


+ 1 


Weighting  function: 

t-a 

l-e  *' 

t-a 

1 + e w 

For  / — » -oo  u(t)  approaches  1,  for  t —3  °°  u(t)  approaches  0.  u(a)=\/2 , w is  the  width 
of  a transition  zone. 


«(/)  = — • 
' 2 


Expansion  function: 


w, 


’d(t)  = d 


( t V'1 


W 


•exp 


The  final  dependence  is.  determined  by  a weighted  combination  of  the  two  linear  relations  by 
means  of  the  “sigmoid”  function  u plus  an  expansion  with  the  2-parametric  Weibull  density 
function  wd. 


*(0  = u{* ) • g\  (* ) ■ + (1  ~ u(t ))  ■ • g2  (* ) ' + wd{t) . 


These  formulas  can  be  used  to  represent  both  the  lower  and  the  upper  limit  curves,  of  course  with 
different  sets  of  coefficients.  The  coefficients  dx,sx,d2,s2,a,w,d,b,c  are  determined  by  means 
of  a non-linear  least  squares  fit  of  z(t)  to  the  individual  lower  and  upper  limit  curve  tables. 
Figure  7 shows  an  example  of  the  construction  of  the  combined  upper  limit  curve,  plotted  versus 
the  number  of  flights.  The  topmost  line  is  gx , whereas  the  lowest  line  is  g2 . The  coefficient  s2  is 
the  slope  of  the  limit  curve  for  a large  number  of  flights,  because  u(t\wd(t)— > 0 for  large  t. 
This  makes  s2  equivalent  to  a long-term  P-factor,  i.e.  it  gives  an  asymptotic  life  consumption  for 
large  number  of  accumulated  flights. 
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Figure  7:  Construction  of  upper  limit  curve  for  small  number  of flights 


Figure  8:  Construction  of  limit  curve  continued 

The  example  in  Figure  8 shows  the  same  (upper)  limit  curve  as  in  Figure  7,  but  for  a larger 
numbers  of  flights.  The  influence  of  gl  has  diminishes  at  1000  flights,  but  there  is  still  some 
offset  caused  by  the  expansion  function  shown  as  near  horizontal  curve  near  the  flight  number 
axis.  The  numerical  cycle  values  z(t)  shown  in  both  figures  give  a good  impression,  how  the 
plausible  range  may  vary  for  short  and  long  time  cycle  accumulation.  Whereas  a life  consumption 
of  44.3  cycles  is  plausible  for  10  accumulated  flights,  a corresponding  life  consumption  of  443 
cycles  for  100  accumulated  flights  has  a nearly  vanishing  probability,  at  least  if  the  assumption  of 
random  mission  assignment  is  not  severely  violated. 

The  limit  curves  derived  from  the  simulations  were  used  in  a first  step  to  check  all  Group-A  part 
data  in  the  BMS  database  for  a plausible  relation  between  accumulated  flight  time  and 
accumulated  cyclic  life  usage.  Figure  9 shows  a comparison  of  the  limit  curves  predicted  by  the 
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fleet  simulation  with  accumulated  life  usage  data,  for  a component  that  has  been  monitored  by 
OLMOS  from  its  entry  into  service.  The  scatter  of  the  actual  data  is  slightly  higher  than  the 
predicted  scatter.  This  is  caused  by  the  comparatively  small  number  of  recorded  flights  that  were 
available  to  determine  the  distribution  parameters  for  the  underlying  “damage  per  flight” 
distribution. 


Predicted  limits 


Figure  9:  Comparison  of  simulation  results  with  actual  life  usage  data 


A significant  difference  in  data  quality  was  found  between  parts  that  were  actually  used  in  flying 
engines  and  spare  parts.  Due  to  the  system  philosophy,  that  only  parts  used  in  an  engine  are 
checked  for  consistency,  the  frequency  of  data  errors  was  higher  in  the  spare  parts  inventory,  than 
it  was  for  the  actively  used  parts.  Especially  those  parts,  where  changes  of  the  monitoring 
algorithms  had  been  performed  in  the  past,  showed  a higher  percentage  of  inconsistent  usage 
data.  This  was  at  least  partially  caused  by  incomplete  conversions  of  data  after  the  introduction  of 
new  life  usage  algorithms.  Whereas  the  conversion  of  LUM  data  between  subsequent  versions  is 
designed  as  an  automatic  process,  the  conversion  of  results  from  earlier  versions  usually  requires 
some  manual  interference. 

We  found  a significant  connection  between  the  accessibility  of  parts  and  the  frequency  of 
implausible  data  records  in  the  BMS  inventory.  It  was  not  very  surprising,  that  a correlation 
existed  between  the  required  maintenance  level  to  access  a part  and  the  frequency  of  data 
inconsistencies.  Parts  that  were  only  accessible  at  industry  or  in  the  central  repair  facilities  of  the 
air  force  (e.g.  disks  of  the  HP  compressor)  had  fewer  data  errors  than  parts  that  were  changed  at 
squadron  level  (e.g.  HP  turbine  cover  plates).  For  frequently  changed  or  easily  accessible  parts  it 
may  be  therefore  be  worthwhile  to  increase  also  the  frequency  of  the  plausibility  checks. 


Correction  of  implausible  life  usage  data 


Figures  10  and  11  illustrate  the  method  to  be  applied,  when  the  number  or  accumulated  cycles  is 
found  outside  the  plausibility  band.  It  is  assumed,  that  the  accumulated  flight  time  could  be 
confirmed  to  be  correct.  Whereas  the  conservative  correction  in  Figure  10  assumes,  that  no 
historical  data  are  available,  Figure  11  reflects  the  situation  currently  found  in  the  handling  of  the 
data  from  the  OLMOS  system,  where  monthly  snapshots  of  all  life  usage  data  are  stored  and  kept 
within  a database  maintained  at  industry.  The  availability  of  historical  data  turns  out  to  be  quite 
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beneficial  and  avoids  the  necessity  for  worst-case  assumptions  for  the  whole  life  in  case  of  data 
errors. 


Accumulated  Flight  Time 

Figure  10:  Conservative  Correction  of  Outliers 


Accumulated  Flight  Time 


Figure  11:  Correction  Using  Stored  Historical  Data 

Influence  of  Usage  Monitoring  on  Life  Cycle  Costs 

Within  the  engine  monitoring  functions  the  computation  of  the  life  consumption  of  the  fracture 
critical  group  A components  represents  the  most  extensive  and  also  most  substantial  part 
regarding  its  effects  on  the  total  costs  of  the  weapon  system.  The  accurate  information  on  the 
state  of  life  usage  in  the  whole  fleet  provides  an  excellent  basis  for  the  planning  of  workload  in 
overhaul  facilities,  spare  parts  manufacturing,  fleet  management  and  financial  requirements.  A 
typical  distribution  of  life  usage  determined  by  OLMOS  is  shown  in  Figure  12. 


Figure  12:  Typical  distribution  of  life  consumption  at  half  nominal  life 

Using  such  data  enables  predictions  of  expected  replacement  costs  as  shown  in  Figure  13. 
Included  in  this  figure  is  an  expected  trend  of  disk  replacement  costs  for  the  USAF,  that  is 
characteristic  for  aging  fleets  without  application  of  individual  life  usage  monitoring  (Source: 
[BloOl]).  One  of  the  benefits  of  individual  life  usage  monitoring  is  the  identification  of 
components  with  low  life  usage  that  permits  to  limit  the  rising  of  costs,  which  would  occur  if 
replacement  were  only  based  on  accumulated  flight  time.  A comprehensive  discussion  of  these 
benefits  is  found  in  [R.TOTR28]. 


Figure  13:  Predicted  replacement  needs  for  a compressor  disk 
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On  the  other  hand  the  maintenance  of  a sophisticated  monitoring  system  also  is  a not  negligible 
cost  factor.  Improvements  in  engine  hardware  have  to  be  modeled  in  updated  monitoring 
algorithms.  Some  benefits  will  not  become  visible  until  an  update  of  the  whole  monitoring 
processing  chain  has  been  performed.  A reasonable  balance  has  to  be  found  between  the 
additional  effort  of  updating  the  monitoring  system  and  the  cost  reductions  expected  from 
application  of  the  best  available  algorithms.  Each  attempt  to  reduce  the  development  and 
investment  costs  for  monitoring  should  take  into  account  the  well-known  cost  relation  shown  in 
the  following  Figure  14  (Source:  [A100]). 


Conclusions 

This  presentation  is  based  on  the  experiences  that  were  made  in  the  last  one  and  a half  decades 
during  the  introduction  and  the  operation  of  the  OLMOS  system.  These  findings  can  be  used  on 
the  one  hand  during  a still  ongoing  improvement  and  optimization  of  this  system.  On  the  other 
hand  they  form  a wealth  of  experience  that  can  and  should  help  to  design  and  implement  new 
monitoring  systems  as  efficiently  as  possible. 

References 

[A100]  Alford  L.D.:  Supporting  Commercial  Software.  CROSSTALK,  The  Journal  of  Defense 
Software  Engineering,  Vol.13,  No. 9,  pp. 13-16,  September  2000 

[BloOl]  M.Blodgett  et  al.:  Residual  Stress  Measurement  Needs  for  Component  Life  Extension: 
An  Air  Force  NDE  Perspective. 

28th  Annual  Review  of  Progress  in  Quantitative  Nondestructive  Evaluation. 

Bowdoin  College,  Brunswick  Maine,  July  29  - August  3, 2001 

[BP97]  Broede  J.,  Pfoertner  H.:  OLMOS  in  GAF  MRCA  Tornado  - 10  Years  of  Experience  with 
On-Board  Life  Usage  Monitoring. 

Paper  AIAA  97-2905,  33rd  AIAA/ASME/SAE/ASEE  Joint  Propulsion  Conference,  Seattle,  1997 

[BPR98]  Broede  J.,  Pfoertner  FL,  Richter  K.:  The  importance  of  testing  for  successful  life  usage 
monitoring  systems.  In:  Proceedings  of  the  19th  Symposium  Aircraft  Integrated  Monitoring 
Systems  (AIMS98),  Garmisch-Partenkirchen,  1998,  pp.  387-406 


(SYB)  3-14 


[CT98]  Clapp  J.A.,  Traub  A.E.:  A Management  Guide  to  Software  Maintenance 
In:  COTS-Based  Systems.  Guidebook  MP98B0000069,  Electronic  Systems  Center, 

The  MITRE  Corporation,  Bedford  MA,  1998 

[HM98]  Hall  S.R.,  Miner  J.W.R.:  Technical  Data  Management:  An  Essential  Tool  for  Effective 
Life-Cycle  Management. 

Proc.  of  the  NATO/RTO-MP-7  Specialists  Meeting,  Exploitation  of  Structural  Loads/Health  Data 
for  Reduced  Life  Cycle  Costs.  Brussels  1998 

[HC99]  Hall  S.R.,  Conquest  T.J.:  The  Total  Data  Integrity  Initiative  (TDIA2)  - Structural  Health 
Monitoring,  The  Next  Generation! ! 

USAF  1999  ASIP  Conference,  San  Antonio,  TX  1999 

[NRC01]  National  Research  Council  Committee:  Aging  Avionics  in  Military  Aircraft. 

Air  Force  Science  and  Technology  Board  Division  on  Engineering  and  Physical  Sciences. 
National  Academy  Press,  Washington  D.C.,  2001 

[PB01]  Pfocrtncr  H.,  Broede  J.:  Statistical  Correlations  for  Analysis  and  Prediction  of  Turbine 
Engine  Component  Life  Usage. 

Paper  AIAA  2001-3754,  37th  AIAA/ASME/SAE/ASEE  Joint  Propulsion  Conference, 

Salt  Lake  City,  UT  2001 

[RTOTR28]  RTO  AVT  Panel  Task  Group  AVT-017:  Recommended  Practices  for  Monitoring 
Gas  Turbine  Engine  Life  Consumption. 

RTO-TR-28  AC/323(AVT)TP/22,  RTO/NATO  April  2000. 


List  of  Acronyms 

BMS 

COTS 

DAU 

DWS 

ELCMP 

FDR 

GAF 

HHC 

HHT 

HP 

IP 

LP 

LUM 

OGS 

OLMOS 

OPCOM 

RBA 

SSTU 


Logistics  system  for  configuration,  material  tracking  and  management 

Commercial  Off  the  Shelf 

Data  Acquisition  Unit 

Departure  Warning  System 

Engine  Life  Consumption  Monitoring  Program 

(Solid  State)  Flight  Data  Recorder 

German  Air  Force 

Hand  Held  Computer 

Hand  Held  Terminal 

High  Pressure 

Intermediate  Pressure 

Low  Pressure 

Life  Usage  Monitoring 

OLMOS  Ground  Station 

Onboard  Life  (Consumption)  Monitoring  System 

Operator  Control  and  Measurement  Computer 

Recorder  Beacon  Airfoil 

Signal  Stimulation  Unit 
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Paper  3:  Discussion 
Question  from  D Shepherd  - OinetiO.  UK 

Were  the  data  outliers  simply  identified  on  the  basis  of  being  outside  of  the  predicted  range  or 
were  you  able  to  go  back  and  positively  confirm  a problem  with  the  actual  data? 

Presenter’s  Reply 

The  margins  used  to  detect  outliers  are  chosen  to  be  very  conservative  and  we  were  always  able 
to  confirm  data  handling  problems  that  generated  the  implausible  results.  If  an  engine,  or  aircraft, 
is  constantly  operated  in  an  extreme  role,  then  the  assumptions  used  in  the  plausibility  checks  are 
violated  and  an  outlier  may  tum  out  to  be  a valid  result.  However,  we  have  never  identified  such  a 
situation  but  if  it  were  to  occur,  an  analysis  of  the  results  for  single  flights  (raw  flight  data)  or  the 
downloaded  data  after  every  flight  would  be  necessary. 


